<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Eclipse Platform/Core</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css">
</head>
<body>
<center>
	<font class=indextop>core</font><br>
	<font class=indexsub>the foundation of the platform</font><p></p>
	<a href="../../main.html">[home]</a>
	<a href="../../documents.html">[documents]</a>
	<a href="../../downloads.html">[downloads]</a>
	<a href="../../resources.html">[resources]</a>
	<a href="../../planning.html">[planning]</a>
	<a href="../../testing.html">[testing]</a>
</center>
<br>
<table BORDER=0 CELLPADDING=2 WIDTH="100%" >
	<tr> 
		<td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">Background Notification</font></b></td>
	</tr>
	<tr> 
		<td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
    	<td WIDTH="98%"><b>Summary</b> 
			<blockquote>
				
        <p>Currently the preference mechanism sends out change notification (for 
          both preference value changes and node changes) immediately after the 
          action is performed and before the method returns. In essence, we set 
          the preference value, iterate over all the appropriate listeners, notify 
          each with a constructed change event, and then return from the #setValue 
          method. </p>
				
        <p>There are a few obvious problems with this approach and the Core team 
          is considering moving event notification into a background job to work 
          around these problems. The purpose of this document is to outline the 
          problems at the Core level and to guage the effect on clients at the 
          UI level.</p>
			</blockquote>
			<p>&nbsp;</p>
		</td>
	</tr>
	<tr> 
		<td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">Core Issues</font></b></td>
	</tr>
	<tr> 
		<td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
    	<td WIDTH="98%"><b>Pros for moving noticication to the background</b> 
			<p><ol>
				<li>Protect against deadlocks. When calling client code, there is always the chance for deadlock. Consider
				the following block of seemingly innocent code:<br>
				<code><pre>
synchronized void foo() {
   ...
   preferences.setValue(key, value);
   ...
}</pre></code> 
			With the current code the notification will occur within the sychronized method. This means there is a chance that
			the client listener code can deadlock.
			</p></li>
				<li>Protect against bad listeners. Consider the following code:<br>
				<code>
          <pre>
new IEclipsePreferences.IPreferenceChangeListener() {
   public void preferenceChanged(PreferenceChangeEvent event) {
      ...
      preferences.setValue(key, value);
      ...
   }
}
</pre>
          </code>
          <p> In the best-case scenerio, the listener is reacting to a change 
            in preference-key-1 and setting a new value for preference-key-2. 
            This will send off another round of notification and that will be 
            the end of it. In the worse-case scenerio the client is making a change 
            to the same preference key that is in the event. In this case, we 
            are looking at a recursive call and, eventually, stack overflow problems. 
          </p>
        </li>
				
        <li>Performance. Clients are able to write whatever they want in their 
          listener code and it may not be performant. If we return immediately 
          from the call to #setValue, then the clients who are calling this method 
          will not have to wait before continuing their execution.</li>
			</ol></p>
		</td>
	</tr>
	<tr> 
		<td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
    	<td WIDTH="98%"><b>Cons against moving noticication to the background</b> 
			<ol>
				<li>
          <p>Client assumptions about the current code. Although it isn't specified 
            in the API, existing clients could be relying on the current implementation 
            and they could be expecting change events to happen immediately after 
            the change itself, and in a sychronous manner. </p>
        </li>
			</ol>
			<p>&nbsp;</p>
		</td>
	</tr>
	<tr> 
		<td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">UI Issues</font></b></td>
	</tr>
	<tr> 
		<td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
    	<td WIDTH="98%"><b>Problems with the current implementation</b>
			<ol>
        <li>The JFace API does not explicitly specify that preference changes 
          must happen (and preference change events occur) within the UI thread. 
          In the current code base, any clients who call the JFace preference 
          APIs in the non-UI thread risk having problems occur. <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=77280">Bug 
          77280</a> describes this problem. In fact, it has already been acknowledged 
          that there are clients who call this code from the non-UI thread and 
          hence the creation of the <code>IPreferenceStore#putValue</code> API 
          method. This method sets values in the preference store without providing 
          listener notification. 
          <p></p>
        </li>
        <li>The JFace API does not specify whether or not the property change 
          notification happens in the same thread that the change happened. </li>
      </ol>
			<p>&nbsp;</p>
		</td>
	</tr>
	<tr> 
		<td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
    	<td WIDTH="98%"><b>Problems with having the Core notification in the background</b> 
			<ol>
			
        <li>Client assumptions about the current code. Clients may be relying 
          on the fact that by the time they return from their <code>IPreferenceStore#setValue</code> 
          calls, all client listeners will have been notified.</li>
			</ol>
			<p>&nbsp;</p>
		</td>
	</tr>
</table>


</body>
</html>